Computer networks are no longer closed systems in which a user's mere presence on the network can serve as proof of identity. In this age of information interconnection, an organization's network may consist of intranets, Internet sites, and extranets—all of which are potentially susceptible to access by unauthorized individuals who intend to maliciously view or alter an organization's digital information assets.
There are many potential opportunities for unauthorized access to information on networks. A person can attempt to monitor or alter information streams such as e-mail, electronic commerce transactions, and file transfers. Your organization may work with partners on projects of limited scope and duration, with employees whom you know nothing about, but who, nonetheless, must be given access to some of your information resources. If your users have a multitude of passwords to remember for accessing different secure systems, they may choose weak or common passwords to more easily remember them. This not only provides an intruder with a password that is easy to crack, but also one that will provide access to multiple secure systems and stored data.
How can a system administrator be sure of the identity of a person accessing information and, given that identity, control which information that person has access to? Additionally, how can a system administrator easily and securely distribute and manage identification credentials across an organization? These are issues that can be addressed with a well-planned public key infrastructure.
A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs) and other registration authorities (RAs) that verify and authenticate the validity of each party that is involved in an electronic transaction through the use of public key cryptography. Standards for PKIs are still evolving, even as they are being widely implemented as a necessary element of electronic commerce. For detailed information about planning a PKI and using public key cryptography, see Resources on public key infrastructure.
There are a number of reasons why an organization may choose to deploy a PKI using Windows:
Strong security. You can have strong authentication with smart cards. You can also maintain confidentiality and the integrity of transmitted data on public networks by using Internet Protocol security and the confidentiality of stored data by using EFS (encrypting file system).
Simplified administration. Your organization can issue certificates and in conjunction with other technologies eliminate the use of passwords. You can revoke certificates as necessary and publish certificate revocation lists (CRLs). There is the ability to use certificates to scale trust relationships across an enterprise. You can also take advantage of Certificate Services integration with the Active Directory directory service and policy. The capability to map certificates to user accounts is also available.
Additional opportunities. You can exchange files and data securely over public networks, such as the Internet. You have the ability to implement secure e-mail using Secure Multipurpose Internet Mail Extensions (S/MIME) and secure Web connections using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). You can also implement security enhancements to wireless networking.
The
The standard certificate format used by Windows certificate-based processes is X.509v3. An X.509 certificate includes information about the person or entity to whom the certificate is issued, information about the certificate, plus optional information about the certification authority issuing the certificate. Subject information may include the entity's name, the public key, and the public-key algorithm.
Users can manage certificates using the Certificates MMC console. For more information, see Certificates overview. Users can also allow certificate autoenrollment to manage their certificates automatically. For more information, see Planning for autoenrollment deployment.
Administrators can manage Certificate Services using the Certification Authority MMC console. For more information, see Certificate Services overview.
Certificate templates are customizable in
Administrators can manage Certificate Templates using the Certificate Templates MMC console. For more information, see Certificate Templates.
Certificate autoenrollment. Autoenrollment allows the administrator to configure subjects to automatically enroll for certificates, retrieve issued certificates, and renew expiring certificates without requiring subject interaction. This requires no knowledge by the subject of any certificate operations, unless the certificate template is configured to interact with the subject or the CSP requires interaction (such as with a smart card CSP). This greatly simplifies the experience of the client with certificates and minimizes administrative tasks.
Administrators can configure autoenrollment through configuration of Certificate Templates and CA settings. For more information see Planning for autoenrollment deployment.
Smart card support. Windows supports logon via certificates on smart cards, as well as the use of smart cards to store certificates and private keys. They can be used for Web authentication, secure e-mail, wireless networking and other public key cryptography-related activities. For more information, see Smart Cards.
Public key policies. You can use Group Policy in Windows to distribute certificates to subjects automatically, establish common trusted certification authorities, as well as managing recovery policies for EFS (Encrypting File System). For more information, see Public Key Policies overview